Amadey Loader

Amadey in nutshell

Amadey is a malware loader first discovered in 2018, primarily used by cybercriminals to deploy additional payloads onto infected systems. Known for its simplicity and efficiency, Amadey enables threat actors to distribute stealers, banking trojans, and ransomware while maintaining a low detection footprint. It is often distributed through phishing emails, exploit kits, or malicious spam campaigns. Unlike more advanced botnets, Amadey focuses on stealth and persistence, making it a valuable tool for cybercriminals. Recently, Amadey has been observed distributing RedLine Stealer and Vidar Stealer, commonly used in credential theft and financial fraud. The loader is also leveraged by Russian-speaking underground forums, making it a persistent threat in cybercrime operations. In online interview, Amadey’s author clears that he developed this malware because SmokeLoader didn’t meet the requirements of his work and developed his own tool. That’s why Amadey was created.

Tech Summary

• Host Profiling: Amadey collects system details like OS version, user privileges, antivirus status, and domain membership to adapt its behavior, evade sandboxes, and customize payload delivery.

• Configuration Extraction: Uses custom Base64 encoding to encrypt configurations stored in the .rdata section, decrypting them dynamically to hide from static analysis. Extracted data includes C2 addresses, execution parameters, and persistence settings.

• C2 Communication: Utilizes WinINet APIs with encrypted HTTP requests to communicate with its C2 server, sending host data and retrieving commands. It ensures persistence by retrying failed connections.

• Payload Deployment: Supports multiple execution methods, including downloading EXE/DLL payloads, injecting shellcode, dropping malware in hidden directories, and modifying registry keys or scheduled tasks for persistence.

• Malicious Code Execution: Employs stealth techniques like process injection, unmapping legitimate executables, COM-based scheduled tasks, and Temp directory re-execution to maintain presence and evade detection.

Analysis

Initial Triage

Field	Value
File Type	PE32+ executable (GUI) x86-64, for MS Windows
File Size	591.23 KiB
MD5	4EC4CA62CD91B6E9DDD4327DB8A36BFE
SHA1	8FC4B3C9E628F3368EE50186806C5790D0E68C21
SHA256	A00ED97F90DA21D37AA31B844C2F7CDE66C7CAE5A70AD60310D7F1F671360C16

In the initial stage of analysis, I got the sample with hash MD5: 4EC4CA62CD91B6E9DDD4327DB8A36BFE, static techniques were sufficient to examine the sample. Loading the file into Detect It Easy (DIE) revealed that it contained a compressed RAR archive. Upon extracting this archive, three files were found:

• book.exe – A suspicious executable
• book.xlsx – A decoy Excel spreadsheet
• luncher.bat – A batch script responsible for execution

Behavior of the Batch Script

The batch script (luncher.bat) behavior Includes executing only three lines of code:

start "" "book.exe"
start "" "book.xlsx"
del "%~f0"

Its purpose is straightforward:

• It launches book.exe, initiating the malicious payload.
• It opens book.xlsx, likely to divert suspicion and make execution appear legitimate.
• It self-deletes to remove traces of execution.

Unpacking and Identifying the Payload

To further investigate, I uploaded the sample to unpac.me, which successfully unpacked the payload. The unpacked executable was identified as Amadey malware, with the same hash as book.exe extracted earlier using DIE. This strongly suggests that the first stage functions as a packer or dropper, designed to deliver and execute Amadey while maintaining stealth. The batch script facilitates execution while erasing evidence, a common tactic in malware deployment.

I’ve uploaded the sample to Traige Sandbox and from the dynamic behaviour and the Triage Report clear that this intial sample only drops the three files and runs the batch script and the file book.exe does all the work.

From this point, I give all my attention to the file book.exe and the coming analysis is all about it.

Field	Value
File Name	book.exe
File size	429.00 KiB
File Type	PE32 executable (GUI) Intel 80386, for MS Windows
MD5	DAA3F1F23DDDF4CF413B75E3F2A75DF7
SHA1	0398FF609DCF5B8E0D580FBB4C68E8511EF8880B
SHA256	7F8FC4871723C0813A17E211D62CB069764E5B5A692852616DF82E7F3A2EFB2A

Host profiling

The Amadey malware executes book.exe as its primary payload, initiating operations such as persistence, C2 communication, and host profiling. During host profiling, it collects critical system attributes—including OS version, antivirus presence, and domain details—and sends them to its C2 server. This information helps attackers assess the infected machine, adapt malware behavior, evade detection, and target specific organizations or environments.

Extracted Host Profiling Parameters

The malware collects the following system-related information:

Identifier	Value
id	Unique identifier of the infected system, possibly generated based on hardware and user-specific values.
os	Operating system version, used to determine compatibility with malware execution.
vs	Version of the malware or related software on the system.
pc	Computer name, which can be used for identification or network-based attacks.
sd	System directory path, potentially used for storing malicious files or persistence.
av	Installed antivirus software, useful for evasion techniques.
bi	Build information of the system, which may indicate specific Windows distributions or architectures.
ar	Administrator rights status, determining whether the malware runs with elevated privileges.
lv	Additional malware installed on infected machine.
og	Organization or domain name, often extracted for targeting enterprise environments.
un	Current username, useful for determining access levels and privileges.
dm	Domain membership status, relevant for targeting corporate networks.

Persistence

During the analysis of the malware sample, it was observed that it establishes persistence using Windows Scheduled Tasks. This technique ensures that the malware remains active even after a system reboot or user logoff, allowing it to maintain control over the infected machine.

Scheduled Task and Job Creation

Scheduled Task via COM Interface

The malware establishes persistence by creating a Scheduled Task using the Task Scheduler COM API instead of traditional methods like schtasks.exe or registry modifications. By leveraging hardcoded CLSIDs and RIIDs, specifically CLSID {148BD52A-A2AB-11CE-B11F-00AA00530503} (representing ITaskScheduler) and RIID {148BD527-A2AB-11CE-B11F-00AA00530503} (representing ITask).

The malware interacts directly with the Task Scheduler service. This technique enables stealthy execution and evasion from detection mechanisms that monitor command-line activity.

Once initialized, the malware creates a scheduled task that executes a malicious malware copied to the Temp directory, typically found at: C:\Users\<Username>\AppData\Local\Temp\Gxtuum.exe

The task is configured to run at system startup or user logon, ensuring persistence across reboots. To make the task less noticeable in the Task Scheduler UI. By using CoCreateInstance to instantiate ITaskScheduler and ITask.

• The malware first checks wether it runs from the Temp or another folder.
• If it runs from the Temp ignore the task creation and if not it creates the task..

This persistence mechanism poses a significant challenge for detection and mitigation, as it bypasses command-line monitoring and process-based detection.

Job Creation

The malware also creates a job associated with the scheduled task, likely serving as a wrapper for executing additional commands or payloads in a controlled manner.

Copy into Temp

After establishing persistence, the malware verifies whether it is running from the Temp Folder. If it is not, it copies itself to the designated location within Temp, executes from there, and terminates the current process to ensure execution from the intended path.

The process follows these steps:

• Retrieves the Temp Folder path.

• Appends the subdirectory name cca1940fda where the malware will reside.
• Assigns the filename Gxtuum.exe for execution.

• Uses the GetModuleFileNameA API to obtain its current execution path.

• Compares the current path with the intended Temp location:
  • If already running from the correct path, it proceeds with execution.
  • If not:
    • Checks if the cca1940fda directory exists:
      • If the malware file (Gxtuum.exe) is present and accessible, it executes from there.
      • If the file is missing or inaccessible, it copies itself to the directory and then runs from the new location.
    • If the directory does not exist, it creates it, copies itself to Temp, and executes from there.

This mechanism ensures that the malware consistently operates from the Temp Folder, likely to evade detection and maintain control over execution.

---

• make_copy_0

  

---

• shell_excute

  

---

Machine Temp Folder

Mutex

The malware employs a mutex (Mutual Exclusion Object) as part of its execution flow. A mutex is a synchronization primitive that allows the malware to enforce single-instance execution, preventing multiple copies from running simultaneously. This technique is commonly used by malware to avoid conflicts and potential detection by security tools that monitor multiple active processes. Mutex name 44c9c3d1e2ec0331790f629dd3724d02

Amadey reuses the mutex name as a rc4 Key for encrypt and decrypt data in communication with the C2 server.

Configurations

In the second stage, Amadey stores its encrypted configuration data within the .rdata section. However, during execution, these configurations are dynamically relocated to the .data section and the heap for decryption. The malware decrypts its configuration inline, meaning decryption occurs at the point of use rather than storing it in a fully decrypted form. Once used, Amadey erases the decrypted data from the heap, retaining only the encrypted configuration to hinder forensic analysis.

Decryption Process

Before executing its main functionality, Amadey identifies and loads its encrypted configurations from the .rdata section. These configurations appear to be stored in a custom base64-like encoding. Initial attempts to decode them using standard base64 methods yielded unreadable results, suggesting an additional layer of obfuscation.

By tracing cross-references (xrefs) to these structures, I observed that before utilizing the configurations, the malware decrypts them and prepares them for execution.

Within the decryption function, Amadey follows a two-step process to decode its encrypted configurations:

• Custom Base64 Decryption:
  • The malware first calls a function responsible for decrypting its custom base64-encoded configuration data.
  • This suggests the use of a proprietary encoding scheme rather than standard base64, likely implemented to evade detection and complicate analysis.

• Standard Base64 Decoding:

  • Once decrypted from its custom format, the data is then passed to a second function that performs standard base64 decoding.
  • This final step converts the now-readable data into its actual usable form before execution.

By employing this multi-layered approach, Amadey increases the complexity of analysis, ensuring its configurations remain obfuscated until the malware is actively running.

Decryption

Decrypt the custom base64

As previously mentioned, the configuration data is stored in a custom base64 format, and this function is responsible for converting it into standard base64 for further decoding..

Algorithm

The function primarily consists of one main loop for iterating through the encrypted configuration characters and two inner loops for setting up the decryption process.

• First Inner Loop: Finding Character Index in Custom Base

  • Before entering the loop, the function ensures that the custom base64 character set used for encryption is loaded into memory.
  • It then enters an infinite loop, iterating through this custom character set.
  • The goal of this loop is to search for each character in the encrypted configuration within the custom base and return its index (char_index).

---

• Second Inner Loop

  • The second loop functions similarly to the first but operates on a key set, another in-memory character set stored dynamically in the .data section.
  • The purpose of this loop is to find the index of a corresponding letter from the key set.

  

  • For each character in the encrypted configuration, a corresponding character in the key set is determined based on its index.
  • If the encrypted config length is greater than the key length, the key is reused cyclically.
    • And this issue is being handled in a prior function used to set the decryption key depends on the length of the encrypted configurations.
  • This loop retrieves and returns the index (key_index) of the matched character.

• Decryption Process

  • Once the two indexes are retrieved (char_index from the custom base64 encrypted and key_index from the key set), the decryption math begins.
  • The function applies an operation on these indexes to derive the final index that corresponds to the actual base64 character.
  • This allows the malware to reconstruct the original base64-encoded configuration, which can then be decoded into plaintext for use.

Decode Base64

After the main decryption loop, the function returns a standard base64-encoded string. This output can now be easily decoded using:

• Python’s built-in base64 library
• Online tools like CyberChef

configs extractor

To automate the extraction of decrypted configurations, I developed a Python script that simulates the decryption process used by the malware. This script allows for efficiently extracting and analyzing the malware’s configuration settings without manually reversing each instance.

eg. for this algorithm

Encoded Base64: N1iP7RPqGrQZXG== //from the executable
Decoded Base64: R3h0dXVtLmV4ZQ== //after applying the previous algorithm
Decoded String --> Gxtuum.exe  //just decode the output base64 

Command and Control (C2) Communication

Amadey stores its C2 server within its encrypted configuration and decrypts it only when needed. This ensures that the C2 address remains hidden in memory until the malware actively uses it.

Once Amadey completes its setup phase—which includes achieving persistence, profiling the host, and relocating itself to the Temp folder for execution—it creates a separate thread responsible for handling continuous communication with its C2 server.

C2 Decryption and Execution Flow

• Amadey decrypts both the C2 domain and the requested object at the beginning of the function.
• To obfuscate its execution flow, it heavily relies on stack pointer manipulation, making analysis difficult.
• This technique complicates argument resolution, leading to challenges when analyzing the function in tools like IDA.
• Despite this, I carefully traced function calls and memory manipulations to clarify its communication mechanism.

C2 Comms

Inside the c2_func, Amadey prepares the data necessary for sending requests to its C2 server. Instead of using low-level socket APIs at first, it relies on high-level Windows networking APIs from Wininet.dll.

By using Wininet.dll, Amadey benefits from:

• Evasion – It blends in with legitimate network traffic.
• Simplified communication – Avoids manually handling raw sockets.
• Reliability – Automatically manages connection handling and timeouts.

This method allows Amadey to securely send system data and retrieve commands from its C2 infrastructure while maintaining a stealthy presence on the infected system.

• Initialize the connection

• Read the Data from the server

• Save the data to another variable

• Return the data received from the server

Once the connection is established, Amadey follows a structured approach in its communication with the C2 server.

First Request: Initialization & Sleep Timing

• Amadey opens an HTTP request to the C2 server, sending the optional parameter st=s.
• It expects a response that contains specific commands or configuration values.
• After receiving the response, it parses it by searching for specific markers:
  • <c> – Extracts the command to execute.
  • <d> – Extracts additional data.
• If no relevant data is found, Amadey clears the stack and proceeds to the second request.

Additionally, this first request is used to retrieve the sleep time (dwMillisecond), determining how long the malware should wait before reconnecting if no commands are received.

Second Request: Sending Host Profiling Data

• After handling the first request, Amadey prepares and encrypts system information collected during host profiling using RC4 encryption.
• This encrypted data is then sent to the C2 server in a follow-up request.
• If no valid response is received, the malware clears memory, exits c2_func, and sleeps for the configured time before retrying the connection.

This two-step approach ensures that Amadey efficiently receives commands while maintaining persistence, adapting its behavior based on C2 responses

Processing C2 Commands

After Amadey successfully sends host profiling data to the C2 server, it begins processing the server’s response to determine its next course of action.

Receiving & Storing the Command

• If there is no response from the C2 server, Amadey cleans up memory, sleeps for a predefined period, and retries the connection later.

• If a response is received, it is stored inside the variable server_response, which will be used for further processing.

• The function sub_41E5E0 is responsible for handling this response, and it takes four arguments:

  • server_response – Holds the complete response received from the C2 server.
  • hashtag – Stores the # character, which acts as a delimiter to separate instructions within the response.
  • _lpszServerName – Contains the C2 server’s domain address (185.196.8.37).
  • _lpszObjectName – Contains the request path (/Gd85kkjf/index.php) that the malware queries for further commands.

Parsing the Server Response

• Amadey scans the received response for the presence of #, which acts as a separator between different command sequences.
• If no # is found, execution is redirected to a different function, sub_41CAE0, which likely follows an alternative execution path.

• If # is present, Amadey enters an infinite loop and begins parsing the response, processing each instruction separately.

The break from the loop resides at the end of the loop…

• Amadey processes the C2 server response by iterating through the received data and searching for commands separated by the # delimiter. It dynamically allocates each character and compares it against #, setting a flag (hash_found) once a match is found.

• This allows the malware to identify and extract individual commands efficiently. Each command is executed sequentially, and once all instructions have been processed, Amadey clears its allocated memory, sleeps for a predefined duration, and then reconnects to the C2 server to request new commands.

• This cyclic behavior ensures continuous communication and execution of tasks assigned by the attacker.

str_cmp is a sepcial function for string comapring returns`1` if succeeded and `0` if not.

• After locating the hashtag inside the response the malware starts to excute the command after it from the function sub_14CAE0.

Extracting & Processing Commands

• Inside the function sub_41CAE0, Amadey retrieves a command identifier from the C2 response.

• It extracts one or two bytes from a fixed offset (+8 bytes) in the response data.

• These bytes are then converted into an integer, which determines the execution path in a switch-case block containing 20 different cases.

• Each case corresponds to a specific task that the malware should perform.

Handling Encrypted Payloads

• After identifying the command type, Amadey searches for a + character in the response at a specific position (after 0xB).

• If + is found, it indicates that encrypted data is present in the response.

• Amadey then:
  • Retrieves the encrypted data stored in memory.
  • Decrypts it using the RC4 algorithm to extract the actual command or payload.
  • Proceeds to execute the decrypted instructions.

C2 Communication and Payload Deployment

The malware exhibits a wide range of functionalities, leveraging multiple execution paths to achieve redundancy and flexibility. Its primary capabilities include:

• Payload Deployment & Execution: The malware can drop and execute various payloads, including DLL files such as cred.dll and clip.dll, either directly from the server or by writing them to disk.
• Process Injection: It injects and executes code within other processes, likely for stealth and privilege escalation.
• Persistence Mechanisms: It ensures continued execution through scheduled tasks and registry modifications, specifically editing the RunOnce key.
• Data Exfiltration: The malware collects and sends system-related information, including screenshots, to the remote server.
• Multiple Communication Methods: It initializes and utilizes low-level network APIs for communication, sending different types of data depending on execution flow.
• Redundant Execution Paths: It employs multiple methods to perform the same tasks, ensuring resilience against detection or failure.

This structured approach highlights the malware’s adaptability and multi-faceted design, making it more resistant to security defenses.

payload injection

Get Payload

The payload injection process in Amadey is executed when the command option 13 is received from the C2 server. The malware follows its typical stack pointer manipulation approach before executing the injection, which involves reallocating its arguments before calling the main function responsible for handling the injection: drop_inject.

Once inside drop_inject, the malware initializes a counter with 0 and enters an infinite loop.

Amadey attempts to connect to the C2 server and requests a file. If the request is successful, the downloaded payload is passed to a function that handles the injection process. The malware ensures that the payload is properly retrieved and is ready for execution.

However, if the malware fails to retrieve the payload, it closes any open handles and does not proceed with injection. This failure could occur due to network issues, C2 downtime, or a missing payload.

If Amadey successfully retrieves the payload from the C2 server and the injection function returns 1, which it always does, the infinite loop breaks. This indicates that the malware has completed the payload injection process successfully.

If the payload retrieval counter reaches or exceeds one, Amadey does not continue looping. Instead, it jumps to LABEL_66, where it executes the send_data function. This function transmits predefined data—likely a signal to the attacker—before the malware cleans up its memory and exits the injection function.

This means that Amadey only attempts to retrieve the payload once. If the attempt fails, it does not retry indefinitely but instead follows a structured failure-handling mechanism. This controlled execution ensures that the malware does not remain in a continuous loop if the C2 is unresponsive, reducing unnecessary activity that could trigger detection.

Inject Payload

• The function starts to retrieve the file name of the current executable and stores it in Filename to create another process of it in the suspended state using CreateProcessA API.
• At first, it checks if the payload starts with the magic signature for the pe files MZ and if yes it checks if the signature is PE to make sure the payload is an excutable.
• Allocates memory for the thread context and retrieves the thread context of the suspended process, attempts to read the process memory (likely checking the ImageBase).
• Calls NtUnmapViewOfSection to remove the existing executable from the newly created process.
• Allocates memory in the remote process for the new executable image.
• Writes the headers of the new PE file into the target process.
• Iterates over the sections of the PE file and copies each section into the newly allocated memory space.
• Writes the new base address into the process memory and updates the EAX register with the new entry point.
• Finally, sets the modified context and resumes execution.
• Then the function returns 1.

IOCs

No	Description	Value
0	Parent SHA-256	a00ed97f90da21d37aa31b844c2f7cde66c7cae5a70ad60310d7f1f671360c16
1	Amadey SHA-256	7f8fc4871723c0813a17e211d62cb069764e5b5a692852616df82e7f3a2efb2a
2	Excel File SHA-256	e88ebdfae363fc3805a58eb91016bdc7b53cd2e5cab7c7abe38f467d3a15b8aa
3	Batch Script SHA-256	6f4adbd5ce608fb86c84ab4fae255c823d4bc587bc1e3787d9d644fa2abd3a76
4	C2	185.196.8.37/Gd85kkjf/index.php, 185.196.8.37/Gd85kkjf/Plugins/cred.dll, 185.196.8.37/Gd85kkjf/Plugins/clip.dll
5	Temp Folder	cca1940fda
6	Running Process	Gxtuum.exe
7	Dropped Files	crdd.dll, clip.dll, Gxtuum.exe, book.exe, Book.xslx
8	Created Job	Gxtuum.job
9	Mutant	44c9c3d1e2ec0331790f629dd3724d02

yara

Coming Soon

References

Latest Version of Amadey Introduces Screen Capturing and Pushes the Remcos RAT

Amadey: New encoding with old tricks

Amadey Threat Analysis and Detections